System and method for generating dynamic playlists utilising device co-presence proximity

ABSTRACT

The invention provides a system and method for generating dynamic playlists utilising device co-presence proximity comprising the step of identifying of music preferences by analysing the listening history on a device of a user; and recognising what devices are co-present within a set proximity for the purposes of matching such devices.

CLAIM OF PRIORITY

This application claims the benefit of priority to U.S. ProvisionalPatent Application No. 62/141,396, titled “System and method forgenerating dynamic playlists utilising device co-presence proximity”,filed Apr. 1, 2015, which is herein incorporated by reference.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

FIELD OF INVENTION

The present invention relates generally to a method, system andapparatus for the generation of dynamic playlists by understanding whatmedia content has been played by one or more users.

DESCRIPTION OF RELATED ART

There are currently more than 2 billion smartphone devices in the world.These smartphones perform many of the functions of a computer, typicallyhaving a touchscreen interface, Internet access, and an operating systemcapable of running downloaded apps.

A movement towards the increased portability of media has followed thistechnical advancement through the benefits of the client to serverrelationship on which these electronic devices operate. This means thatmedia, and music specifically, can be accessed by smartphone owners ondemand and in a number of different ways. For example, music can beconsumed by listening to local MP3 files on the phone itself or throughaccess to the Internet or through dedicated apps on the phone.

In addition, the rise of on demand music streaming services with theirvast catalogues of millions of songs means that ownership of a physicalmusic file or a digital music file is no longer required to enjoy music.The state of the art allows subscribers to access this content wheneverand wherever they want on their smartphones through any number of freeor paid subscription services. The net result is that it has never beeneasier to listen to music on the go either in an individual or groupcapacity.

The existence of all this easily accessible content has led to consumersnow facing an overwhelming song choice as there are often over 20million tracks available on most of the established content providers.In order to combat this ‘search bar paralysis’ when looking for music, anumber of services have introduced dedicated playlist functionality toallow consumers to sort and make sense of these vast databases of music.

The curation of music into playlists or other queues of specific songsis well established but this was often driven by a limitation of accessto content as opposed to consumers having too much choice. By way ofexample, when CDs were the state of the art, it was common that CDs wereplayed during a party to entertain the guests. However, such party-goerscould only listen to the music that was physically present at thatparty. Other listeners would have to bring their own CDs to the party ifthey wanted to extend the scope of the music listened to or if theysimply wanted to demonstrate their music preferences. Such limitationsprohibited the communal enjoyment of music.

With the advent of the Internet and digital music in general, thislimitation was removed for the first time and synchronous musiclistening was no longer limited to the content physically present at anyone location. To take the example of a house party again, party-goerswould often take turns in choosing the music that was being played on adesktop computer or laptop from a much broader catalogue of music.Despite these advancements, this process was relatively manual andrequired the primary music player (desktop computer or laptop) to becontrolled by one person at a time.

Another limitation of this approach was that the music played wastypically dictated by the person who was in control of the primary musicplayer at the party. Without knowing what the preferred music tasteswere of the other party-goers the controller of the primary music playerhad no way of understanding what the most popular choice of music wouldbe for that particular environment. It was also difficult therefore toqueue songs and create playlists of music that would be enjoyed by agroup as a whole. This is especially true the larger the group inquestion. It is next to impossible for example to work out what themusical preferences for a nightclub crowd would be even though thiswould be highly valuable for any DJ at that night club. Equally, atlarger music festivals it is very difficult without resorting to manualprocesses to poll the attendees to find out what their music listeningpreferences are.

Arguably, the only place where this type of group curation workedsynchronously was in virtual online music rooms such as Turntable.fm.The reason this platform worked (growing to a registration base of 40million users) was that it combined instant music streaming with chatrooms and a voting system. In sum, it provided the content, the socialdialogue around the music being played and the ability for listeners toup-vote or down-vote the song being listened to. Turntable.fm thereforesolved some of the problems of listening to music synchronously becauseusers were able to access listening histories, preferences and real-timereactions to adapt the music that was being played on the service tobetter suit the group that were consuming the music.

Other services tried to meet the desired listening preferences of agroup by using an asynchronous approach. Instead of requiring users tolisten to the same music at the same time, services like Spotifyencouraged collaboration around playlists that could then be listened toby an individual or a group at a later point of time. By representingindividual tastes in a collaborative manner, it was hoped that thisasynchronous approach could solve the above-mentioned problemsassociated with enjoying music in a group. Namely the control issuewhere one party-goer had to rely on a best guess to play the right musicfor that environment and to suit the tastes of all participants. Thepreloaded playlist could then be enjoyed in a synchronous manner by thecontributors to the playlist when they were next together in a group.

With the widespread adoption of smartphones, there should be a way forgroups of people to enjoy music together by combining the advantages ofeasily accessed content with a better understanding of musicpreferences. In addition this solution should be automated and notreliant on manual user input on demand. It is an object therefore toprovide a solution for a system and method for generating dynamicplaylists.

SUMMARY

According to the invention there is provided, as set out in the appendedclaims, a system and method for generating dynamic playlists utilisingdevice co-presence proximity.

The invention specifically targets this problem by understanding whatmusic each individual in a group has been listening to historically andthen working out when those individuals are within a certain proximityto one another. This is achieved by analysing the media content playedon a smartphone and by recognising when two smartphones are in the samelocation.

To take the example of the house party again, this solution does notrequire any manual input, social dialogue or voting system to work outthe aggregated tastes of a group. Instead when a playlist is generatedby any party-goer, the queue of songs to be played will updateautomatically when new people enter the room. This removes any frictionin choosing what song to play next and eradicates the guesswork involvedin trying to work out the best music to play for that particularenvironment.

The present invention is an improvement over conventional systems inthat method and apparatus for the generation of dynamic playlists byunderstanding what media content has been played by a listener and thenmerging this media content utilising co-presence proximity between twoor more electronic devices. This invention is both unique and animprovement over the prior art.

It is therefore an object of the present invention to provide a new andimproved method and apparatus for the generation of playlists in anautomated and efficient manner when in a group.

It is another object of the present invention to provide a new andimproved music or other audio metadata identification system and methodin respect of music or other media played on a smartphone to understandthe listening preferences of a user.

It is another object of the present invention to provide a new andimproved device co-presence recognition system at the operating systemlevel on smartphones.

It is another object of the present invention to provide a new andimproved device co-presence recognition system and method that iscapable of working with real-time GPS location-based systems as well aspre-loaded mapping software on smartphones.

It is another object of the present invention to provide a new andimproved device co-presence recognition system and method that iscapable of working with Bluetooth wireless technology.

It is another object of the present invention to provide a new andimproved device co-presence recognition system and method that iscapable of working with temporal-based systems so that such informationis filterable by time.

It is another object of the present invention to provide a new andimproved device co-presence recognition system and method that iscapable of being used by app developers to provide users with theability to generate music playlists and other audio metadata on otheronline platforms.

Other objects, features and advantages of the invention will be apparentfrom the following detailed disclosure, taken in conjunction with theaccompanying sheets of drawings, wherein like reference numerals referto like parts.

There is also provided a computer program comprising programinstructions for causing a computer program to carry out the abovemethod which may be embodied on a record medium, carrier signal orread-only memory.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be more clearly understood from the followingdescription of an embodiment thereof, given by way of example only, withreference to the accompanying drawings, in which:

FIG. 1 is a diagram of a system for identifying music or other audiometadata on a mobile device.

FIG. 2 is an example of the various music sources that can be analysedto understand listening preferences.

FIG. 3 is a diagram of the server to client interaction that is used toimplement an embodiment of the invention.

FIG. 4 is a first way that a mobile communication device 1 can becomeaware of other nearby mobile communication devices.

FIG. 5 is a second way that a mobile communication device 1 can becomeaware of other nearby mobile communication devices.

FIG. 6 is a third way that a mobile communication device 1 can becomeaware of other nearby mobile communication devices.

FIG. 7 is a schematic view of how the invention uses Bluetooth proximitymatching to work out what devices are nearby.

FIG. 8 is a schematic view which explains how the GPS identificationworks in the present invention.

FIG. 9 is a schematic view of the GPS proximity matching method used.

FIG. 10 is a schematic view of how the invention uses local area networkproximity matching to work out what devices are nearby.

FIG. 11 is a schematic view of the discovery process working.

FIG. 12 is a schematic view of the monitoring process working.

FIG. 13 is a schematic view of the matching process working.

FIG. 14 is a schematic view outlining the system used for automaticclassification and human classification of songs.

FIG. 15 is a diagram of device co-present proximity in operation at ahouse party to generate dynamic playlists.

FIG. 16 is a picture of the invention working using a central mediaplayer and TV.

FIG. 17 is a diagram of device co-present proximity in operation at amusic festival to generate dynamic playlists.

DETAILED DESCRIPTION

A method and apparatus for the identification of music or other audiometadata played on an iOS device, and more particularly, in relation toaudio files that are played through the native iPod application on iOSdevices.

While this invention is susceptible of embodiment in many differentforms, there is shown in the drawings and will herein be described indetail several specific embodiments, with the understanding that thepresent disclosure is to be considered merely an exemplification of theprinciples of the invention and the application is limited only to theappended claims.

Although several embodiments of the invention are discussed with respectto music or other audio metadata on iOS devices, in communication with anetwork, it is recognized by one of ordinary skill in the art that theembodiments of the inventions have applicability to any type of contentplayback (e.g., video, books, games) involving any device (wired andwireless local devices or both local and remote wired or wirelessdevices) capable of playing content that can be identified, or capableof communication with such a device.

FIG. 1 is a diagram of a system for identifying played content on amobile device, according to one embodiment. By way of example, thecommunication between push of location, timestamp, metadata and userdetails at 102 between the device 101 and the backend 103 and thecommunication between the pull of location, timestamp, metadata and userdetails at 105 between the backend 103 and the content provider 105 caninclude one or more networks such as a data network (not shown), awireless network (not shown), a telephony network (not shown) or anycombination thereof.

The system set out in FIG. 1 included a music identification andclassification service 101, 102, 105 and 106 and a database interfaceprocess 103. The system includes instructions for finding metadata aboutmusic or other audio files. The database interface process 103 is theinterface between the device 101 and the content database 106, and isused to retrieve and store metadata, and to retrieve and store content.

In the illustrated embodiment, the services include played contentidentification process 102 and 105 to identify played music or otheraudio metadata and to use the database interface process 103 to storeand retrieve the event data that describes what is being played, whereit being played and when.

In circumstances where the music or audio metadata is not stored on thedevice 101, and pushed 102 to the database 103, often a ContentDistribution Network (CDN) as embodied in 106 is the source of the musicor audio metadata. Typically, the music store authorizes the CDN todownload the client and then directs a link on the user's browser clientto request the content from the CDN. The content is delivered to theuser through the user's browser client as data formatted, for example,according to HTTP or the real-time messaging protocol (RTMP). As aresult, the content is stored as local content 106 on the user's device101. The local content arrives on the device either directly from theCDN or indirectly through some other device (e.g., a wired note likeother host) using a temporary connection (not shown) between mobileterminal for example and other host.

Once this information has been added to the database 103 and storedlocally, the application itself 104 on a user's mobile device can thenbe used to access and retrieve the music or other audio metadata.Depending on the availability of the metadata, user details andtimestamp, an app developer can therefore use the present invention todistinguish what music or other audio file was played, when it wasplayed and by whom.

FIG. 2 is a diagram outlining some of the various sources of musicconsumption 201, including but not limited to mobile native musicplayers, third party players, streaming services, music video services,internet radio and desktop players. The music can be identified from oneor a combination of these sources to understand what their musiclistening history is for a particular user. This information can then besent to a database 202 to be stored for future reference.

In addition to embodiments set out in FIGS. 1 and 2, which a third partyapp developer could use, first party services will have their own musicidentification process to understand what music has been played, when itwas played and by whom. For example, Apple will know what songs arelistened to by a user on iTunes (e.g., on their own particular service)and will not need to push this information from the mobile client orpull it from the service separately into a database. The presentinvention caters for such an embodiment.

FIG. 3 is a diagram of the server to client interaction that is used toimplement an embodiment of the invention. The client-server model ofcomputer process interaction is widely known and used. According to theclient-server model, a client process 301 sends a message including arequest to a server process 303, and the server process responds byproviding a service. The server process 303 may also return a messagewith a response to the client process 301. Often the client process andserver process 303 execute on different computer devices, called hosts,and communicate via a network using one or more protocols for networkcommunications. The term “server” is conventionally used to refer to theprocess that provides the service, or the host computer on which theprocess operates. Similarly, the term “client” is conventionally used torefer to the process that makes the request, or the host computer onwhich the process operates. As used herein, the terms “client” 301 and“server” 303 refer to the processes, rather than the host computers,unless otherwise clear from the context. In addition, the processperformed by a server can be broken up to run as multiple processes onmultiple hosts (sometimes called tiers) for reasons that includereliability, scalability, and redundancy, among others. In this case,the client 301 pushes plays 302 to the server 303 which then returns theaggregated results of the plays 304 back to the client 301.

FIGS. 4, 5 and 6 show three ways that a first mobile communicationdevice 401, in accordance with one novel aspect, can become aware ofsecond mobile communication devices 402 and 403 located nearby the firstmobile communication device 401.

FIG. 4 illustrates how first mobile communication device 401 detectsnearby second mobile communications devices 402 and 403 using Bluetoothcommunications. Each mobile communication device has a Bluetoothtransceiver and communication functionality. Block 404 represents theBluetooth communication functionality 404 within first mobilecommunication device 401. When device 401 enters the Bluetoothcommunication range of devices 402 and 403, periodic device inquirybroadcasts by device 401 are received by the other devices 402 and 403.Each other device responds to such a device inquiry by sending back aresponse. The response contains position information indicative of theposition of the originator of the response. The response also containsan identifier that uniquely identifies the originator. In this way, amobile communication device 401 that has a Bluetooth communicationfunctionality can become aware of the presence of other nearbyBluetooth-enabled mobile communication devices 402 and 403. Whether ornot the devices 402 and 403 are determined to be nearby (or in the“presence of”) mobile communication device 401 is determined by whetheror not Bluetooth communication can be established between the devices.If Bluetooth communication can be established, then it is determinedthat the second mobile communication device must be nearby the firstmobile communication device. If Bluetooth communication cannot beestablished, then it is determined that the second mobile communicationdevice is not nearby the first mobile communication device.

It should also be noted that the present invention utilises the latesttechnologies in mesh networks to ensure that devices that might be outof range directly with one another can still be ‘paired’ to a masterdevice. A mesh network has a topology whereby all devices cancommunicate with all other devices in the network, either directly if inrange, or indirectly via one or more intermediate “nodes” if they arenot. This is in contrast to other network types that often feature acentral hub like a router, through which all traffic must flow. Meshnetworks have no such central hub and offer multiple ways of gettingdata from one device to another. This makes for an inherently reliablenetwork design. It will be explained in FIG. 16 how such a mesh networkmight operate in order to match numerous co-present devices in order togenerate a dynamic playlist.

FIG. 5 illustrates another way that first mobile communication device501 can become aware of other nearby second mobile communication devices502 and 503. In the example of FIG. 5, each mobile communication deviceis a cellular telephone that has a Global Positioning System (GPS)functionality. The GPS functionality of first mobile communicationdevice 501 is identified by reference numeral 506. Each cellulartelephone reports its location, as determined by its GPS functionality,via a cellular telephone communication link to a base station 504 of thecellular telephone network or through a GPS satellite 505. The locationsof mobile communication devices 502 and 503 are then relayed via thecellular telephone network to mobile communication device 501. Mobilecommunication device 501 is aware of its own location by virtue ofinformation generated by its own GPS functionality 506. First mobilecommunication device 501 can therefore compare the GPS locationinformation of all the devices 501-503 to determine that devices 502 and503 are nearby (in the “presence of”) device 501.

FIG. 6 illustrates another way that first mobile communication device601 can become aware of other nearby second mobile communication devices602 and 603. In the example of FIG. 6, each mobile communication deviceis a cellular telephone that has a wireless LAN (Local Area Network)functionality by which it can communicate with an Access Point 604 ofthe wireless LAN. The wireless LAN functionality of first mobilecommunication device 601 is represented by reference numeral 605. Mobilecommunication device 601 is aware that it is close to Access Point 604by virtue of its being in RF communication with Access Point 604.Similarly, mobile communication devices 602 and 603 also are aware thatthey are close to Access Point 604 because they are in RF communicationwith Access Point 604. Devices 602 and 603 communicate their locationsvia Access Point 604 to first mobile communication device 601. Inaddition, the use of WiFi fingerprinting can be utilised to work out ifmobile devices are nearby to one another. For example, if it is knownwhat WiFi networks are near first mobile device 601 and what WiFinetworks are near second mobile device 602 then if there is significantoverlap between the two, it can be determined that first mobile device601 and second mobile device 602 are near to one another. This ishelpful in situations where there is no connection to a local accesspoint. These are just a couple of examples on how a local area networkand WiFi signal can be used to determine device proximity.

FIG. 7 is a schematic view of how the invention uses Bluetooth proximitymatching to work out what devices are nearby. In this embodiment, theexecution starts 701 when the first mobile device initialises aBluetooth communication protocol 702. The First mobile device thentransmits a signal using the Bluetooth communication protocol 703. If areturn signal is transmitted by another device 704 then the first mobiledevice compares the signal strength to the predetermined threshold 705.If no return signal is transmitted by another device 704 then theexecution stops until there is trigger event which causes the firstmobile device to react 708. Such a trigger may include a time delay orany such other arbitrary trigger event as chosen. If there is a returnsignal transmitted by another device 704 and the first mobile device hascompared the signal strength to the predetermined threshold 706, it willthen be confirmed if the signal strength is within the set proximity706. If it is, then the devices will be matched 707. If it is not, thenthe execution will be stopped until some subsequent trigger eventactivates the process all over again 708. It should be noted that theinvention includes a number of optimisations that help with battery lifeusing the latest technological improvements available through Bluetoothlow energy (BLE). By adhering to these latest developments, we canensure that we only check for Bluetooth proximity matching as and whenrequired. By including these engineering constraints we can ensure thatthe overall user experience is a positive one as the draining of batteryfor background tasks such as this is not intended nor desired.

FIG. 8 is a schematic view which explains how the GPS identificationworks in the present invention. In this embodiment, the execution starts801 when the first mobile device requests the GPS location (usingcellular networks and/or satellite as available) 802. If there is anavailable GPS position for the first mobile device 803 then the firstmobile device sets the GPS position as the current location 804. ThisGPS location is then sent to the server and stored in a geospatialdatabase 805. If there is not an available GPS position for the firstmobile device 803 then upon a subsequent trigger event, it will bechecked again whether or not this is an available GPS lock for the firstmobile device 806. If there is then the first mobile device will set thenew GPS position as the current location 807. The invention will thenwait a set amount of time or for a triggered event to see if the devicehas moved 808 and the process will commence again with the first mobiledevice requesting the GPS location 802. If there is no available GPSlock for the first mobile device 806 then the first mobile device willcheck in parallel if location information is available from otherpositioning modules (e.g., Bluetooth or LAN).

FIG. 9 is a schematic view of the GPS proximity matching method used. Inthis embodiment, the execution starts 901 when the first mobile deviceGPS location is identified 902. The first mobile device then sends arequest to the geospatial database 903 and checks if there are any othermobile devices within the set proximity 904. If there are then thesystem will match the devices 905. If there are no other devices withinthe set proximity then the first mobile device requests the GPS locationand the cycle begins again 906 as outlined in more details in FIG. 8.

FIG. 10 is a schematic view of how the invention uses local area networkproximity matching to work out what devices are nearby. In thisembodiment, the execution starts 1001 when the first mobile deviceinitialises a local area network (LAN) 1002. Once identified, the firstmobile device initialises communication in the LAN 1003. Next, the firstmobile device transmits a signal on the LAN 1004 and checks to see ifany signals are received from other mobile devices on the LAN 1005. Ifno other signals are received then the execution stops and reactivatesupon a trigger event 1007 and the process commences again with the firstmobile device transmitting a signal on the LAN 1004. If a signal isreceived from another mobile device as queried at 1005 then the firstmobile device compares signal strength to the predetermined threshold1006. It then checks if the signal strength is within the set proximity1008. If it is then the system will match the devices 1009. If thesignal strength is not within the set proximity then the execution stopsand reactivates upon a trigger event 1007 and the process commencesagain with the first mobile device transmitting a signal on the LAN1004.

It should be noted that these are separate embodiments of the locationmodules working in isolation from one another. The invention utilisesthe best available location module (whether that is by GPS, LAN,Bluetooth or otherwise) for each particular scenario in order to matchdevices and to minimise the battery drain. Often these systems can berun in parallel and the optimisations occur in near real-time betweenthe client and server depending on the specific use case.

FIG. 11 is a schematic view of the discovery process working (agnosticto any particular location or communication protocol module). The firstmobile device 1101 identifies the device ID 1102. The User ID is thenpolled through the app and sent to the server 1103. Separately, thesecond mobile device 1104 identifies the device ID 1105. The User ID ofthe second mobile device is then polled through the app and sent to theserver 1106. Once the IDs have been identified, the first mobile devicescans for others using the best location discovery module 1107 for thatparticular situation. The second mobile device responds to the scanningsignal indicating that in this case it does implement the currentinvention 1108. The discovery modules on each of the two devices thenexchange their respective device ID and User ID expressions 1109. Eachof the two discovery modules that share the identity expressions arethen labelled as ‘matched’ devices 1110 and the matching process iscommenced 1111 which is further described in FIG. 13. To ensure that thedevices remain connected, a monitoring process is then commenced 1112 asfurther outlined in FIG. 12.

FIG. 12 is a schematic view of the monitoring process working (agnosticto any particular location or communication protocol module). The firstmobile device 1201 and the second mobile device 1202 have at this stagealready been matched. It should be noted that once a match is made, thesystem monitors that the devices are connected using device IDexpressions only as there is no need to check if User ID expressionsmatch through the server and this could get expensive over a givenperiod of time. Another reason why the system monitors using device IDsis to deal with use cases where one particular might have multipledevices (mobile phone, iPad and desktop) while using just one user IDfor the app on each device. By matching device ID we can thenunderstanding listening habits on each unit and provide a morecomprehensive overview of musical tastes when matching preferences.

The monitoring commences when the first mobile device tries to find thenext/first matched device using known device IDs 1203. Next, the firstmobile device scans for the next/first device using the best location orcommunication discovery module for that particular situation 1204. Ifthe device ID is matched 1205 then the process begins again and thefirst mobile device tries to find the next/first matched device usingknown device IDs 1203. If the device ID is not matched then thediscovery process is commenced to search for the next device 1206 and asfurther described in FIG. 11.

FIG. 13 is a schematic view of the matching process working (agnostic toany particular location or communication protocol module). In the firstinstance, the server having identified the first mobile device,generates a playlist based on an API call from the first mobile device1301. The first mobile device then displays this playlist 1302. Onceanother device is matched, a request is sent to the server to poll forother device User IDs 1303. The server then analyses the other deviceUser ID for that user's respective listening history 1304. Then if thereis any human classification into the desired outcome of the amalgamatedplaylist 1309 a combined playlist is generated by the server using thepredetermined human input filters 1309. If no human classification isreceived 1305, a combined playlist is automatically generated by theserver 1306. In either case, whether by generated automatically orthrough human input, the first mobile device then displays the combinedplaylists 1307 which can then be consumed synchronously through thefirst mobile device 1308.

Again, there is an overlap between the discovery, monitoring andmatching modules between various devices at certain points in time andthis is system is optimised for each particular scenario in order tomatch devices and to minimise the battery drain.

FIG. 14 is a schematic view outlining the classification system used inthe present invention for automatic classification and humanclassification. For the purposes of this description, it is notelaborated on how the human classification operates but suchclassification systems are well recognised in the state of the art. Forexample, a host of the party may want to dictate that the music playedsuits a particular mood (e.g., pop music). By using a filter for thegenre of pop music, only songs 1401 that correlate to this humanclassification 1403 will be added as classified songs 1404 to thedynamically generated playlist as and when people enter the room and thedevices are matched due to their proximity to one another. By way ofanother example, a DJ at a music festival, utilising the co-presencetechnology, can predetermine the tempo of the songs that they wanted toinclude in the dynamic playlist that is generated during a set. Thiscould be set to 120 BPM to create a more upbeat and lively atmosphere.Once this human classification 1403 has been set, only the correspondingclassified songs 1404 would then be amalgamated into the dynamicplaylist.

If no human classification is included then the invention uses anautomatic classification system 1402 which will result in classifiedsongs 1404 based on that method.

FIG. 15 is a diagram of a practical example of how the present inventionoperates by showing the indoor floor plan of a house and the positioningof a number of devices within that house. In this case, the first mobiledevice 1501 is the master device which is being used to play music at ahouse party. In this example, we have set an arbitrary proximity rangeof −60 dB. Any wireless signals which transmit a frequency to the firstmobile device 1501 within that set proximity are recognised as beingwithin the necessary distance threshold from one another and matched.The second mobile device 1502 is −36 dB away from the first primarymobile device. The system then begins the matching process as set out inFIG. 13 and the playlist is dynamically generated based on the chosenclassification system. The third mobile device is initially outside ofthe proximity range set 1505 with a reading of −80 dB. If the owner ofthat third mobile device then moved into the room where the music wasbeing played, 1506 the first mobile device would recognise that thisdevice was within range and the matching process would commence. The neteffect of this change in position by the owner of the third mobiledevice is that once inside the room 1506, the party playlist woulddynamically change based on the listening history of that person asadjusted to the classification system chosen (if any). The fourth mobiledevice 1504 is outside of the predetermined range with a reading of −123dB and never moves into the room. The playlist is therefore not updatedby the presence of this device. Similarly, the fifth mobile device isnot within the predetermined range with a reading of −115 dB. As such,the playlist would not be updated by accounting for the listeninghistory and tastes of the owner of that device either.

FIG. 16 is an example of the invention working using a Google NexusPlayer as the media device and using a TV to show the playlist that isbeing generated dynamically. The Google Nexus Player has a wirelessconnection using Bluetooth 4.1 and so any devices with Bluetoothcapabilities are able to communicate with the media system. First thesoftware is installed on the Google Nexus Player 1601. The Google NexusPlayer is then connected to the TV to demonstrate the media playerfunctionality. When a new user walks into the room and their mobiledevice is matched 1602, they will appear on the application as a matcheddevice. The invention looks at the listening history for each matcheddevice and updated the playlist 1603 accordingly. As people enter andleave the room, this playlist changes dynamically. The playlist can belistened to 1604 at any stage and the songs queued in the playlist willupdate based on the presence of other devices in the room.

FIG. 17 is a diagram explaining how the invention can be used at a musicfestival. In this example, the primary media device is 1702 iscontrolled by a DJ who is playing his set on the main stage 1701 of thefestival. A proximity threshold of −90 dB is set for wirelesscommunications and so only devices within this range will be directlymatched with the primary media device. So in this example, the secondmobile device 1703, with a reading of −68 dB and the third mobile device1704 with a reading of −72 dB, are within the proximity threshold andare therefore matched with the primary media device 1702.

In this case, the fourth mobile device 1705 with a reading of −93 dB isoutside of the proximity threshold set of −90 dB from the primary mediadevice 1702. However using the latest developments in mesh networks onthe Bluetooth communication protocols, the system can indirectly connectthe fourth mobile device 1705 with the primary media device 1702 throughthe second mobile device 1703. This is because there is a distance of−35 dB between the fourth mobile device 1705 and the second mobiledevice 1703 which is within the proximity threshold set. The fourthmobile device 1705 can therefore communicate (through the second mobiledevice 1703) with the primary media player 1702 and will the fourthmobile device 1705 be recognised as a paired device. The matchingprocess can then commence as outlined in FIG. 13. Equally, the sixthmobile device 1707 is well outside of the proximity threshold with areading of −128 dB from the primary media player 1702. The sixth mobiledevice 1707 can however communicate indirectly with the primary mediaplayer 1702 though the fourth mobile device 1705 and/or the secondmobile device 1703. Similarly, using this approach the fifth mobiledevice 1706 and the seventh mobile device 1708 can communicate with theprimary media player 1702.

The DJ can therefore update his set list based on the musicalpreferences of those in attendance at the music festival, not just thosewho might be already at the main stage and within the proximitythreshold. One can imagine how the use of the Bluetooth mesh networkcould be used in other situations to understand what taste preferencesare matched between devices that are close to one another but notdirectly within range of a location or communication protocol.

Thus the reader will see that at least one embodiment of the systemprovides a new and improved way to generate dynamic playlists utilisingdevice co-presence proximity. Furthermore, the method and apparatusdescribed has the additional advantages in that:

-   -   it identifies content in the most efficient manner possible        using complimentary methods to ensure that the correct song is        identified;    -   it allows for the graphing of music tastes by understanding what        music a user has been listening to;    -   it allows for the recognition of co-present mobile devices using        a number of different location and communication modules;    -   it allows for both an automated process and human input process        when classifying what media items to include in a playlist;    -   it allows for such playlists to be generated in real-time and        updated according to the music preferences of the matched        devices that are present;    -   it provides a mechanism for users to then consume the songs that        have been smoothed in any given playlist.

In accordance with an embodiment, an apparatus comprises at least oneprocessor; at least one memory including computer program code, at leastone memory and the computer program code configured to, with the atleast one processor, cause the apparatus to perform identifying of musicpreferences by analysing the listening history on a device of a user.

In accordance with an embodiment, the at least one processor and the atleast one memory are further configured to initiate recognition of whatdevices are co-present within a set proximity for the purposes ofmatching such devices.

In accordance with an embodiment, the at least one processor and the atleast one memory are further configured to initiate classification ofhow the content that is matched across the matched devices is to begenerated.

In accordance with an embodiment, the at least one processor and the atleast one memory are further configured to generate a dynamic playlistbased on the devices being co-present within a set proximity and usingsuch a classification system as desired by a user.

In accordance with an embodiment, the apparatus is adapted to merge themedia content utilising co-presence proximity between two or moreelectronic devices and generating a dynamic playlist for two or moredevices.

In accordance with an embodiment, the improvement of matching process byadapting to the best location or communication module for each specificsituation.

In accordance with an embodiment, the system optimises the matchingprocess in order to save battery life of any matched mobile devices.

In accordance with an embodiment, a method for generating dynamicplaylists utilising device co-presence proximity comprises the step ofidentifying of music preferences by analysing the listening history on adevice of a user; and recognising what devices are co-present within aset proximity for the purposes of matching such devices.

While the above description contains many specificities, these shouldnot be construed as limitations on the scope, but rather as anexemplification of one or several embodiments thereof. Many othervariations are possible. Accordingly, the scope should be determined notby the embodiments illustrated, but by the appended claims and theirlegal equivalents.

The embodiments in the invention described with reference to thedrawings comprise a computer apparatus and/or processes performed in acomputer apparatus. However, the invention also extends to computerprograms, particularly computer programs stored on or in a carrieradapted to bring the invention into practice. The program may be in theform of source code, object code, or a code intermediate source andobject code, such as in partially compiled form or in any other formsuitable for use in the implementation of the method according to theinvention. The carrier may comprise a storage medium such as ROM, e.g.,CD-ROM, or magnetic recording medium, e.g., a memory stick or hard disk.The carrier may be an electrical or optical signal which may betransmitted via an electrical or an optical cable or by radio or othermeans.

In the specification the terms “comprise, comprises, comprised andcomprising” or any variation thereof and the terms include, includes,included and including” or any variation thereof are considered to betotally interchangeable and they should all be afforded the widestpossible interpretation and vice versa.

The invention is not limited to the embodiments hereinbefore describedbut may be varied in both construction and detail.

What is claimed is:
 1. An apparatus comprising: at least one processor;at least one memory including a computer program code, wherein the atleast one memory and computer program code are configured to, with theat least one processor, cause the apparatus to identify a user's musicpreferences by analysing a listening history on a device of a user. 2.The apparatus of claim 1, wherein the at least one processor and the atleast one memory are configured to initiate recognition of devices thatare co-present within a set proximity for purposes of matching suchdevices.
 3. The apparatus of claim 1, wherein the at least one processorand the at least one memory are further configured to initiateclassification of how content across matched devices is to be generated.4. The apparatus of claim 3, wherein the at least one processor and theat least one memory are further configured to generate a dynamicplaylist based on devices being co-present within a set proximity andusing a classification system as desired by a user.
 5. The apparatus ofclaim 1, wherein the apparatus is adapted to merge media contentutilising co-presence proximity between two or more electronic devicesand generating a dynamic playlist for the two or more electronicdevices.
 6. The apparatus of claim 1, wherein a matching process adaptsto a best location or communication module for each specific situation.7. The apparatus of claim 1, wherein a matching process is optimized inorder to save battery life of any matched mobile devices.
 8. A methodperformed by an apparatus having at least one processor, and at leastone memory including a computer program code, for generating dynamicplaylists utilising device co-presence proximity comprising: identifyinga user's music preferences by analysing a listening history on a deviceof a user; and recognising devices that are co-present within a setproximity for purposes of matching such devices.
 9. The method of claim8, wherein the at least one processor and the at least one memory areconfigured to initiate classification of how content across matcheddevices is to be generated.
 10. The method of claim 9, wherein the atleast one processor and the at least one memory are further configuredto generate a dynamic playlist based on devices being co-present withina set proximity and using a classification system as desired by a user.11. The method of claim 8, wherein the apparatus is adapted to mergemedia content utilising co-presence proximity between two or moreelectronic devices and generating a dynamic playlist for the two or moreelectronic devices.
 12. The method of claim 8, wherein a matchingprocess adapts to a best location or communication module for eachspecific situation.
 13. The method of claim 8, wherein a matchingprocess is optimized in order to save battery life of any matched mobiledevices.
 14. A computer readable storage medium having instructionsstored thereon to cause an apparatus having at least one processor, andat least one memory, to carry out a method comprising: identifying auser's music preferences by analysing a listening history on a device ofa user; and recognising devices that are co-present within a setproximity for purposes of matching such devices.
 15. The computerreadable storage medium of claim 14, wherein the at least one processorand the at least one memory are configured to initiate classification ofhow content across matched devices is to be generated.
 16. The computerreadable storage medium of claim 15, wherein the at least one processorand the at least one memory are further configured to generate a dynamicplaylist based on devices being co-present within a set proximity andusing a classification system as desired by a user.
 17. The computerreadable storage medium of claim 14, wherein the apparatus is adapted tomerge media content utilising co-presence proximity between two or moreelectronic devices and generating a dynamic playlist for the two or moreelectronic devices.
 18. The computer readable storage medium of claim14, wherein a matching process adapts to a best location orcommunication module for each specific situation.
 19. The computerreadable storage medium of claim 14, wherein a matching process isoptimized in order to save battery life of any matched mobile devices.